The present invention generally relates to memory devices for use with computers and other processing apparatuses. More particularly, the present invention relates to solid-state mass storage drives and methods for improving write performance while maintaining data integrity in the event of a power failure.
Non-volatile solid-state memory technologies used with computers and other processing apparatuses (host computer systems) are currently largely focused on NAND flash memory technologies, with other emerging non-volatile solid-state memory technologies including phase change memory (PCM), resistive random access memory (RRAM), magnetoresistive random access memory (MRAM), ferromagnetic random access memory (FRAM), organic memories, and nanotechnology based storage media such as carbon nanofiber/nanotube-based substrates. These and other non-volatile solid-state memory technologies will be collectively referred to herein as solid-state mass storage media. Mainly for cost reasons, at present the most common solid-state memory technology used in solid-state drives (SSDs) are NAND flash memory components, commonly referred to as flash-based memory devices, flash-based storage devices, flash-based media, or raw flash.
Due to the requirement to present an SSD as though it were a traditional hard disk drive, a memory controller is required to perform a translation of the hard disk protocols to instructions to read and write the memory of the SSD. This operation requires a memory controller to use large translation and mapping tables and other metadata to assist in this process. FIG. 1 represents a write command being implemented on an SSD 100 of a type known in the art. SSD 100 includes an interface 110 for communicating with a host computer system (not shown), a memory controller 120, a volatile memory 140 used as a buffer, and a non-volatile NAND flash-based memory array 130. The write command is represented as being received by the controller 120 from the host computer system at the command handler 122. The controller 120 writes the command and accompanying data to a write buffer 142 of the volatile memory 140 and a completion status of the command is immediately returned by the command handler 122 to the host computer system. Subsequently, the write buffer 142 of the volatile memory 140 is flushed and a NAND channel controller 124 of the memory controller 120 issues memory page program commands to the NAND flash-based memory array 130. Notably, a single write command from the host computer system may result in the programming of multiple pages in multiple NAND flash memory components and/or dies within the memory array 130. When the memory page program commands have completed, metadata (essentially the physical locations corresponding to the logical locations that the host computer system command specified) is written to a Logical to Physical (L2P) log 146 in the volatile memory 140. The L2P log 146 is used to update an L2P table copy 144 held in the volatile memory 140. The L2P table copy 144 comprises metadata entries identifying the logical to physical locations of the data in the memory array 130.
For reasons of speed and performance, translation and mapping tables and other metadata used by the memory controller 120 are normally read from the memory array 130 of the SSD 100 at initial power-on, then stored in the L2P table copy 144 of the volatile memory 140. In order not to affect performance, the data in the L2P table copy 144 is only periodically flushed back to the memory array 130 during operation, and again when the SSD 100 is properly shut down. Depending on the specific SSD and/or the situation, either the whole L2P table copy may be flushed to the memory array or merely entries in the L2P table copy that have not yet been saved to the memory array may be flushed to the memory array.
The SSD 100 is therefore exposed to a window of time wherein the data and the translation and mapping tables and metadata in the non-volatile memory array 130 are not consistent. If the power to the SSD 100 were to be suddenly removed during this time, the up-to-date translation/mapping tables and metadata in the volatile memory 140 may be lost and unrecoverable. The result may be that when the SSD 100 next powers up, it may not be possible to reconcile the data and translation/mapping tables and metadata stored in the memory array 130 of the SSD 100, and data may be lost.
Various measures have been implemented in the art to protect important data from being lost in the event of a power failure as described above. In particular, Force Unit Access (FUA) is an I/O write command where the storage device must ensure that the data (and any metadata necessary to subsequently read the data) has been written to the non-volatile memory before the command completes, that is, returns a completion status to the host computer system. Therefore, data written by a completed FUA write command is on permanent media even if the storage device is powered off before flushing the volatile memory. FUA write commands are typically used by the journaling file system of the host computer system's operating system to ensure that the file system remains in a self-consistent state in the event of a sudden power loss.
FIG. 2 represents the SSD 100 receiving an FUA write command. As represented, the command handler 126 will cause the data from the FUA write command to be directed to the NAND channel controller 124. Although not shown for clarity, the FUA write command may be temporarily staged or buffered via the volatile memory 140, though for immediate processing and not for later processing as would occur in the case of a standard write. When the memory page program commands complete, the metadata is immediately updated in an L2P table 148 stored in the memory array 130 (although not shown for clarity, the metadata may also be updated in the L2P table 144). Only when the data and the updates to the L2P table 148 have completed is the completion status returned to the host computer system by the command handler 126.
In an SSD that receives an FUA write command, in order to ensure that the data is stored in the non-volatile media, two events have to occur. First, the data must be written to the non-volatile storage media (for example, memory array 130). Second, the L2P table (for example, the L2P table 148) must be updated to define the location of the new data on the non-volatile storage media. Since each of these two events individually require at least one flash page to be written, the latency of the FUA write command will be at least two flash page write times (typically 1-3 ms each). As such, FUA write commands sacrifice operating speed for security of the data. In addition, when multiple write commands, including both FUA and regular, non-FUA write commands, are being processed by an SSD, it can be difficult to track which updates to the L2P table copy have been flushed and to which individual FUA write command they pertain.
In view of the above, it can be appreciated that there are certain problems, shortcomings or disadvantages associated with the prior art, and that it would be desirable if methods and systems were available for processing FUA write commands and/or similar commands while reducing or eliminating the negative impact on write performance and reducing the complexity of tracking updates to the L2P table copy.